Windows Server 2003 : Auditing Events (part 1) - Audit Settings for Objects

12/14/2011 9:11:19 AM

Auditing certain computers, users, and operating system events is a necessary part of network administration. You choose what is to be audited and then, by reviewing the event logs, track usage patterns, security problems, and network traffic trends. Beware of the impulse to audit everything, however. The more events you audit, the bigger the logs. Reviewing huge event logs is a painful chore, and eventually no one looks at them anymore. These logs can take up enormous amounts of space. Therefore, it’s critical to decide on an auditing policy that protects your network without creating a large administrative burden. Also bear in mind that every audited event results in a small increase in performance overhead.

By default, all auditing categories are turned off when Windows Server 2003 SP1 or later is installed except for success audits of logon events. Table 1 lists the categories of events that can be audited.

Table 1. Auditing categories
Event Category	Activated When
Account logon events	A domain controller receives a logon request
Account management	A user account or group is created or changed
Directory service access	An Active Directory object is accessed
Logon events	A user logs on or logs off
Object access	An object is accessed
Policy change	A policy affecting security, user rights, or auditing is modified
Privilege use	A user right is used to perform an action
Process tracking	An application executes an action that is being tracked
System events	A computer is rebooted or shut down or another event occurs that affects security

Every audited event tells you something, but it’s not always something you need to know. For example, auditing successful logons and logoffs might reveal the use of a stolen password, or it might just produce countless pages showing that your duly authorized users are logging on and off as expected. Auditing logon failures, however, will definitely be rewarding if someone is trying a random password hack.

Before you can audit access to Active Directory objects (which is described in the next section), you must turn on the Audit Policy setting by using Group Policy. To enable auditing of any of the categories in Table 1 , open the Default Domain Policy MMC if you have one; otherwise, follow these steps to enable auditing for all computers in the domain:

1.	Launch Active Directory Users and Computers.
2.	Right-click the domain name in the console tree, and choose Properties from the shortcut menu.
3.	Click the Group Policy tab and then click Edit.
4.	In the console tree, click your way through Computer Configuration, Windows Settings, Security Settings, and Local Policies to reach Audit Policy, as shown in Figure 1. Figure 1. Categories of events for auditing
5.	Right-click the event category you want to audit, and choose Properties from the shortcut menu.
6.	In the dialog box that opens, select the check box to define the setting and select the option to audit successful attempts, failed attempts, or both.

Audit Settings for Objects

Assuming that you’ve turned on a policy setting for auditing an Active Directory object, create audit settings for objects by following these steps:

Right-click the object you want to audit, and choose Properties from the shortcut menu. Click the Security tab.

Click Advanced, and then click the Auditing tab.

Click Add to set up auditing for a new group or user. Make your selection and click OK.

Select the events you want to audit, as shown in Figure 2. Table 2 lists the options and their definitions.

Figure 2. Selecting events to be audited

Table 2. File system events that can be audited
Event	Activated When
Traverse Folder/Execute File	A folder is traversed (that is, someone passes through the folder on the way to a parent folder or a child folder) or an application is run.
List Folder/Read Data	A folder is opened or data is viewed in files.
Read Attributes	The attributes of a file or folder are viewed.
Read Extended Attributes	Extended attributes (defined and created by programs) of a file or folder are viewed.
Create Files/Write Data	A file is created inside a folder or a file is changed, overwriting existing information in the file.
Create Folders/Append Data	A folder is created inside the folder being audited or information is added to an existing file.
Write Attributes	A file or folder attribute is changed.
Write Extended Attributes	Extended attributes (defined and created by programs) of a file or folder are changed.
Delete Subfolders and Files	A file or subfolder is deleted.
Delete	A specific file is deleted.
Read Permissions	Permissions for a file or folder are viewed.
Change Permissions	Permissions for a file or folder are modified.
Take Ownership	Ownership of a file or folder changes.

Click OK when finished.

Note

By default, audit settings are inherited by child objects. The Auditing tab of the Access Control Settings dialog box includes a check box for allowing inheritable auditing entries. Clear this check box and the audit settings for the object remain constant, even if the parent object’s audit settings are changed. In addition, clearing this check box removes any audit settings that have already been inherited. The second check box in this tab resets existing auditing and allows audit entries to be inherited from the parent object once again.

Auditing Advisory

Windows Server 2003 allows such granularity that it’s possible—actually easy—to create a real morass when selecting audit settings. So many items can show up in the event log that really important issues might be lost in the crowd. Be very careful when deciding what events need to be audited, and audit as few as is reasonable. You can always add events later as circumstances dictate.